Account Management Taiwan Vps Cloud Server Login Multi-user And Permission Classification Practical Guide

1.

preparation work and prerequisites

- confirm the vps system version (such as ubuntu 20.04 / centos 7) and be able to log in as root or a user with sudo privileges.
- the vps in the taiwan computer room has been opened and the public ip and control panel login information have been recorded.
- it is recommended to back up important configuration files first: /etc/ssh/sshd_config, /etc/sudoers, /etc/group, /etc/passwd.

2.

standard process for creating basic users and groups

- create a new system user and specify the shell and home directory: sudo adduser username or sudo useradd -m -s /bin/bash username.
- create user groups for grouping by responsibility: sudo groupadd devops; add users to groups: sudo usermod -ag devops username.
- check the relationship between group and user: getent group devops or id username.

3.

ssh login method: password vs key (key is strongly recommended)

- generate key pair locally: ssh-keygen -t rsa -b 4096 -c "user@desc" (or use ed25519).
- copy the public key to the vps: ssh-copy-id -i ~/.ssh/id_rsa.pub username@vps_ip, or manually append the public key to /home/username/.ssh/authorized_keys and set permissions (700/.ssh, 600/authorized_keys).

4.

security configuration to limit ssh login (sshd_config)

- edit /etc/ssh/sshd_config, it is recommended to modify: passwordauthentication no, permitrootlogin no.
- use allowusers or match user directive group restrictions, for example: allowusers admin@* devopsuser@*; or more detailed: match group sftpusers chrootdirectory /home/%u internal-sftp.
- restart the ssh service after modification: sudo systemctl reload sshd (or sudo service sshd restart).

5.

configure sudo permission classification for different roles (visudo and /etc/sudoers.d)

- never edit /etc/sudoers directly, use sudo visudo or create a separate file: /etc/sudoers.d/devops.
- example: devops all=(all) nopasswd: /usr/bin/systemctl restart nginx, /usr/bin/journalctl -u myapp; grant only necessary commands.
- verification: sudo -l -u username can view the sudo commands that the user can execute.

6.

set permissions and acls for files and directories to control access granularly

- use traditional permissions to set ownership first: sudo chown root:devops /var/www/app; sudo chmod 750 /var/www/app.
- for more detailed use of acl: sudo setfacl -mu:alice:rwx /var/www/app; view acl sudo getfacl /var/www/app.
- if you need to inherit directory permissions by default: sudo setfacl -d -mg:devops:rwx /var/www/app.

7.

configuring an sftp-only user (chroot jail)

- create a new group sftpusers: sudo groupadd sftpusers; create a user and join the group without shell: sudo useradd -m -g sftpusers -s /sbin/nologin bob.
- add in /etc/ssh/sshd_config: match group sftpusers chrootdirectory /home/%u forcecommand internal-sftp allowtcpforwarding no x11forwarding no.
- make sure that the chroot directory belongs to root and has permissions of 755. the user upload directory is placed in the subdirectory: /home/bob/uploads (chown bob: sftpusers uploads). restart sshd.

8.

key management and revocation policy (when personnel leave or change equipment)

- regularly audit authorized_keys: cat /home/*/.ssh/authorized_keys, record key and purpose.
- revocation method: delete the corresponding public key line or replace authorized_keys; if centralized management (ldap/sso/gitops) is used, revoke at the source.
- if you suspect that a key has been compromised, immediately remove the key from the vps and update the key pair in all related services.

9.

monitoring, auditing and login record viewing

- view login records: sudo last, sudo lastlog, /var/log/auth.log (debian/ubuntu) or /var/log/secure (centos).
- enable command auditing: use auditd (sudo apt install auditd) to add rules to record sensitive commands; sample rules are written to /etc/audit/rules.d/.
- report key logs to a centralized log system (such as rsyslog + elk) for long-term analysis and alerts.

10.

automation and batch account management (script and configuration management)

- create users in batches using scripts: the example simple script reads csv in a loop, executes useradd, mkdir .ssh, writes the public key and sets permissions.
- it is recommended to use ansible to manage users, groups, sudoers and sshd_config to facilitate version control and rollback.
- for large teams, consider combining ldap/ad or radius for unified authentication and group management.

11.

backup and restore account-related configurations

- regularly back up /etc/passwd, /etc/shadow, /etc/group, /etc/gshadow, /home/*/.ssh, and /etc/sudoers.d/*.
- backup script example: tar czf /backup/ssh-config-$(date +%f).tgz /etc/ssh /home/*/.ssh /etc/sudoers.d; and off-site storage (object storage or backup server).
- pay attention to uid/gid consistency when restoring, and verify login and permissions after restoring.

12.

security hardening suggestions and daily maintenance checklist

- force the use of key login, turn off root password login, enable fail2ban to limit brute force attempts, and regularly update system patches.
- enable two-factor authentication for critical operations (e.g. combined with a web control panel or vpn front-end) and periodically change keys and passwords.
- establish account life cycle process: onboarding creation, permission change records, immediate revocation of access upon resignation, and regular audits.

13.

q: how to quickly revoke a user's ssh access on taiwan vps?

q&a example: answer: if you only need to revoke ssh access, the most direct way is to delete/remove the user's public key: sudo sed -i '/ssh-rsa aaaa.../d' /home/username/.ssh/authorized_keys or delete the entire account sudo userdel -r username. if centralized key management is used, please delete the corresponding key at the source and reload sshd. if the account has sudo permissions, it should also be removed from /etc/sudoers.d/ or the group and the relevant logs should be audited.

14.

q: how to restrict the development group to only allow restarting a certain service?

answer: use sudoers file management, create the /etc/sudoers.d/devops file and write: %devops all=(root) nopasswd: /bin/systemctl restart nginx.service. after saving, check with sudo -l. do not grant wildcard commands, make sure the path is accurate and only the necessary commands are listed.

15.

q: are there any recommended least privilege model practices?

answer: the recommended principle is least privilege: group by responsibility, grant access only to specific commands or directories that need to be executed, use acl first when using read-only permissions, enable auditing and log alerts, and use the configuration management tool (ansible) to uniformly issue and rollback policies to keep the configuration auditable and recoverable.